home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000830_TONYJ@scs.slac.stanford.edu _Thu Apr 8 22:25:51 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  2KB
  1. Return-Path: <TONYJ@scs.slac.stanford.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA26320; Thu, 8 Apr 93 22:25:51 MET DST
  4. Received: from SCS.SLAC.Stanford.EDU by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA24596; Thu, 8 Apr 1993 22:45:12 +0200
  6. Date: Thu, 8 Apr 1993 13:44 PDT
  7. From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
  8. Subject: Re: WWW Information Discovery Tools
  9. To: wmperry@guava.ucs.indiana.edu
  10. Cc: www-talk@nxoc01.cern.ch
  11. Message-Id: <9C69093772A094D1@SCS.SLAC.STANFORD.EDU>
  12. X-Envelope-To: www-talk@nxoc01.CERN.CH
  13. X-Vms-To: IN%"wmperry@guava.ucs.indiana.edu"
  14. X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"
  15.  
  16. William M. Perry (wmperry@indiana.edu) writes:
  17.  
  18. >  Well, right now it would be pretty trivial to modify my emacs browser to
  19. >follow _every_ link it finds and record it.  Only problem would be in
  20. >keeping it from getting in an infinite loop, but that wouldn't be too hard.
  21. >Problem would be disk space & CPU time.
  22.  
  23. Unfortunately I don't think infinite loops is the only problem to be solved. 
  24. For example we have databases of Physics Publications accessable via the web, 
  25. and cross-referenced for citations. This databases contain ~300,000 entries. A 
  26. robot, even if it is smart enough to not get into a loop, could spend many days 
  27. roaming this one database trying to find all the entries. One way around that 
  28. would be to have a list of places where the robot should not look, but finding 
  29. this list would itself be a time consuming task. 
  30.  
  31. Conversly there are many interesting documents that can only be accessed by 
  32. giving a keyword, making it difficult for a robot to discover these documents 
  33. at all.  
  34.  
  35. >  Once I get the browser stable, I can work on something like this - unless
  36. >someone else wants to work on it in the meantime.  Might be more
  37. >stable/faster if written in C though. :)  But then what isn't?
  38. >
  39. >  What type of format would the output have to be in?  It would be very
  40. >easy to spit out "URL :: TITLE" into a file.
  41.  
  42. If anyone does solve the problems and generate a "URL :: TITLE" list (possibly 
  43. a few other fields such as last modified date would be useful too) I would be 
  44. happy to try to make the information available through the database we have 
  45. interfaced to WWW.
  46.  
  47. Tony Johnson
  48.